Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

JUN  2009  2' REPORT  TYPE 

3.  DATES  COVERED 

00-05-2009  to  00-06-2009 

4.  TITLE  AND  SUBTITLE 

Evolutionary  Capabilities  Developed  and  Fielded  in  Nine  Months 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

U.S.  Army,  Program  Executive  Office  C3T, Battle  Command, BLDG 
2525-Bay  3, Fort  Monmouth, NJ, 07703 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS (ES) 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF:  17.  LIMITATION  OF 

ARSTRATT 

1 8 .  NUMBER  1 9a.  NAME  OF 

OF  PAGES  RESPONSIBLE  PERSON 

a.  REPORT  b.  ABSTRACT  c.  THIS  PAGE  Same  aS 

unclassified  unclassified  unclassified  Report  (SAR) 

3 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Evolutionary  Capabilities  Developed 
and  Fielded  in  Nine  Months 


Portia  Crowe  Dr.  Robert  Cloutier 

U.S.  Army,  Program  Executive  Office  C3T  Stevens  Institute  of  Technology 

The  DoD  is  facing  challenges  to  rapidly  deploy  operational  capabilities  in  complex  environments  where  bridging  legacy  and 
new  technologies  are  key  to  success.  The  challenges  arise  as  a  result  of  diminishing  budgets  and  the  need  for  new  capabilities 
to  operate  in  war  environments,  including  the  global  war  on  terrorism.  To  balance  this  imperative  need  with  rapid  response, 
we  found  that  our  developed  Agile  life-cycle  paradigm  was  a  viable  solution  to  meet  challenges  brought  about  by  changes  in  the 
environment.  This  article  demonstrates  how  a  DoD  program  used  an  Agile  approach,  throughout  every  phase  of  the  pro¬ 
gram’s  life  cycle,  to  rapidly  field  capabilities. 


Our  intent  with  this  article  is  to  give 
DoD  programs  another  successful 
data  point  for  implementing  an  evolution¬ 
ary  acquisition  strategy  using  Agile  life 
cycle  processes,  and  share  our  learned 
tenets  of  this  process  in  the  hopes  of 
helping  others  rapidly  field  capabilities.  In 
an  environment  where  requirements  are 
unforeseen  and  quickly  changing,  we  need 
our  systems  to  be  flexible  and  adaptable  to 
meet  these  growing  challenges.  Before 
2006,  the  U.S.  Army  readiness  reporting 
system  had  no  longer  met  the  needs  of 
commanders  in  providing  timely  and 
detailed  data  to  make  informed  decisions. 
Complex  environments  and  service-ori¬ 
ented  architecture  (SOA)  changed  the 
landscape  of  operation  and  the  systems 
that  were  operating  in  it.  The  challenge 
was  to,  within  nine  months,  transform  an 
old  Army  readiness  system  to  meet  cur¬ 
rent  needs  without  losing  existing  capabil¬ 
ities  while  also  developing  key  functions 
currently  needed  by  commanders. 

The  solution  was  for  the  Product 
Manager  Strategic  Battle  Command 
together  with  the  Headquarters— Depart¬ 
ment  of  the  Army  G3/5/7  to  modernize 
the  legacy  Army  readiness  application,  PC 
ASORTS,  by  creating  the  Defense  Readi¬ 
ness  Reporting  System- Army  (DRRS-A). 
The  DRRS-A  aligns  with  SOA  strategies 
and  supports  the  demands  of  new  require¬ 
ments,  capabilities,  and  modifications  in 
the  areas  of  force  registration,  force  readi¬ 
ness,  force  projection,  and  mobilization. 
The  DRRS-A  team  included  about  60  peo¬ 
ple  from  the  government  and  multiple  con¬ 
tracting  teams.  The  strategy  was  a  phased 
approach  allowing  for  the  deployment  of 
high-priority  capabilities  first  and  then  sub¬ 
sequent  capabilities  using  an  incremental 
process.  The  DRRS-A  software  system 
first  deployed  in  late  2006  after  only  nine 
months  of  development  and  has  fielded 
new  capabilities  incrementally  in  as  soon  as 
two  months  [1].  The  program  consists  of 
secure  Web-based  capabilities  such  as  unit 


status  reporting  that  details  mission-critical 
information  including  personnel  levels, 
training  status,  equipment  availability,  and 
equipment  serviceability.  It  is  used  as  a 
commander’s  assessment  tool  as  it  reports 
a  unit’s  capability  to  execute  missions. 
Using  an  evolutionary  strategy,  the  legacy 
application  was  a  stepping  stone  for  the 
development  of  new  capabilities  and  rapid, 
yet  disciplined,  transition  of  processes. 

Approach 

The  DoD  embraces  change  after  a  long 
history  of  Waterfall  software  methods  and 
single-step  to  full-capability  approaches. 
The  goal  of  the  DoD’s  Evolutionary 

“In  an  environment 
where  requirements  are 
unforeseen  and  quickly 
changing,  we  need  our 
systems  to  be  flexible 
and  adaptable.9* 


Acquisition  (EA)  policy  is  to  provide  oper¬ 
ational  capabilities  to  the  warfighter — 
quicker  than  traditional  methods — 
through  rapid  incremental  fielding,  build¬ 
ing  to  full-objective  capability  [2].  The 
DRRS-A  implementation  plan  included 
using  the  DoD  EA  approach  as  a  guideline 
for  delivering  capabilities  in  increments. 
Our  evolutionary  strategy  was  to  take  the 
existing  readiness  system  and  perform  sys¬ 
tem  modernization  in  a  phased  approach, 
which  included  leveraging  functionality 
inherent  in  the  old  system  and  translating 
it  into  usable  functionality  in  an  SOA, 
combined  with  serial  guidance  and  direc¬ 
tives  issued  by  the  Joint  Chief  of  Staff. 
The  DRRS-A  currently  has  as  many  as 


5,000  users  including  Army  Commands, 
the  National  Guard  Bureau,  Army  Forces 
Command,  and  the  United  States  Army 
Reserve  Command  (USARC). 

Our  system  methodology  was  to  inte¬ 
grate  all  aspects  of  program  life-cycle 
phases  using  an  Agile  approach  with  rapid 
prototyping  to  ensure  that  the  customer 
and  user  needs  were  met.  We  took  a  linear 
life-cycle  approach  and  worked  life-cycle 
phases  in  parallel  and  often  at  the  same 
time.  Working  within  an  aggressive  sched¬ 
ule,  we  carried  out  continuous  facilitation 
of  the  following  phases: 

•  Concept  refinement,  requirements, 
and  architecture  analysis  and  design. 

•  Capability  and  software  development. 

•  Integration,  testing,  and  demonstra¬ 
tions. 

•  Production  and  deployment. 

•  Operations,  support,  and  training. 

The  user  community  consistently 

worked  with  the  developers  to  refine  con¬ 
cepts  and  requirements  to  be  developed. 
In  a  month,  the  team  could  get  as  many  as 
five  new  requirements  and  enhancement 
requests  from  various  sources,  such  as  the 
readiness  community  and  the  Joint  Chiefs 
of  Staff.  New  requirements  can  range  any¬ 
where  from  new  calculations  to  new  infor¬ 
mation  required  from  the  user.  During 
testing  time,  the  team  mainly  focuses  on 
fixes  and  performance  of  the  applications. 
The  rapid  and  iterative  software  develop¬ 
ment  process  included  conducting  contin¬ 
uous  integration  and  testing  on  a  daily 
basis  by  checking  in  and  out  software 
code.  Scrum,  our  Agile  process,  was 
implemented  in  30-day  software  develop¬ 
ment  sprints  using  a  prioritized  require¬ 
ments  list  also  known  as  a  backlog.  It 
helped  keep  the  focus  on  user  needs  with 
demonstrations  at  the  end  of  each  interval 
[3].  In  a  month,  the  development  and  test 
teams  can  work  through  as  many  as  15 
requirements.  The  Scrum  development 
process  [4]  is  shown  in  Figure  1  (see  next 
page). 
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Rapid  and  Reliable  Development 


Characteristic 

Comments 

Liberty  to  be  dynamic 

Agility  needs  dynamic  processes  while  adhering 
to  acquisition  milestones. 

Non-linear;  cyclical  and  non-sequential 

The  life-cycle  behavior  was  not  like  traditional  waterfall 
models  or  linear  frameworks;  decreasing  cycle  times. 

Adaptive 

Conform  to  changes,  such  as  capability  and  environment. 

Simultaneous  development  of  phase 
components 

Rapid  fielding  time  may  not  lend  to  traditional  phase 
containment  (i.e.,  training  and  software  development  together). 

Ease  of  change 

Culture  shift  to  support  change  neutrality;  ease  of 
modification  built  into  architecture  and  design. 

Short  iterations 

Prototyping,  demonstrating,  and  testing  can  be  done 
in  short  iterative  cycles  with  a  tight  user  feedback  loop. 

Lightweight  phase  attributes 

Heavy  process  reduction,  such  as  milestone  reviews, 
demonstrations,  and  risk  management. 

Table  1:  Emergent  Agile  Characteristics  for  Rapid  Prototype  and  Development 


At  the  end  of  each  development  sprint 
(estimated  as  every  30  days),  a  training 
team  of  six  people  would  develop  or  edit 
training  materials,  user  guides,  and  train 
the  help  desk  on  these  features.  The  user 
community  is  trained  on  the  new  or  edit¬ 
ed  features  via  remote,  computer-based, 
and/or  face-to-face  training.  The  imposed 
user  feedback  loop  gave  us  greater  confi¬ 
dence  that  we  were  building  to  expecta¬ 
tions  and  user  requirements.  We  were  in¬ 
line  with  priorities  as  a  result  of  canvass¬ 
ing  for  feedback  during  bi-weekly  iteration 
meetings,  testing  events,  and  surveys  [5] . 

The  key  to  an  Agile  life  cycle  is  to  keep 
everyone  informed  so  that  functions  can 
be  done  in  parallel.  To  ensure  continuous 
coordination,  all  of  the  functional  leads 
(i.e.,  system  engineers,  development,  logis¬ 
tics,  and  requirement  proponents)  and  key 
users  were  at  every  sprint  review.  This 
helped  to  keep  the  team  in  sync  on  new 
application  features,  training  needs,  inte¬ 
gration  and  test  events,  and  priorities  of 
requirements. 

Interoperability  and  integration  testing 
was  frequently  conducted  not  only  at  the 


subsystems  level  but  for  system  of  sys¬ 
tems  and  external  dependencies.  Prior  to 
major  releases,  we  found  three  to  be  the 
magic  number  of  user  dress  rehearsals  or 
test  events.  These  allowed  users  to  test 
functions  of  the  applications  and  engi¬ 
neers  to  get  a  good  read  on  the  perfor¬ 
mance  of  the  system.  Participants  (usually 
20  to  30  users)  were  chosen  by  the  func¬ 
tions  or  applications  being  tested  during 
that  event  and  the  location  of  participants 
(such  as  Iraq  or  Afghanistan),  which  gave 
us  good  performance  data.  These  testing 
events,  each  lasting  three  days,  usually 
started  three  months  prior  to  a  big  release 
and  were  about  three  to  four  weeks  apart. 
Coordination  with  participants,  training, 
and  test  procedures  distribution  occurred 
prior  to  each  event.  An  online  survey  was 
prepared  for  the  users  to  track  their  issues 
and  concerns  during  the  event.  We  recent¬ 
ly  added  performance  questions  to  track 
how  fast  the  functions  were  loaded  and 
displayed.  After  each  day  of  the  test  event, 
a  configuration  control  board  met  to  dis¬ 
cuss  the  feedback  and  developers  began 
fixing  or  discussing  problems  with  the  test 


event  participants.  This  rapid  test 
approach  allowed  us  to  get  feedback  and 
work  problems  right  away.  Fixes  were 
incorporated  into  the  next  test  event. 
Performance  test  cases  were  conducted 
with  up  to  50  simultaneous  users  doing 
the  same  functions  on  the  force  registra¬ 
tion  application.  During  this  process,  we 
found  memory  leaks  to  be  causing  signifi¬ 
cant  delays  and  were  able  to  be  proactive 
in  optimizing  performance  before  the 
application  went  into  the  field.  Testing 
resulted  in  force  registration,  the  applica¬ 
tion  for  unit  registration  data,  performing 
five  times  faster  when  users  access  the 
most  popular  functions  of  the  application. 
Further  application  testing  led  to  response 
time  improvements  of  up  to  three  times. 
Performance  enhancements  were  made 
where  applications  may  have  many  simul¬ 
taneous  users  in  the  United  States  and 
abroad. 

Learned  Tenets 

Our  rapid  prototyping  and  deployment 
challenge  was  to  take  an  Army  readiness 
reporting  system  that  had  existed  for  12 
years  and  modernize,  deploy,  and  support 
its  new  capabilities  within  nine  months. 
This  brought  about  challenges  for  our 
multiple  contract  teams  who  were  behold¬ 
en  to  many  stakeholders,  not  to  mention 
being  rigidly  adherent  to  changing  require¬ 
ments  in  a  complex  wartime  environment. 
These  Agile  and  rapid  fielding  initiatives 
led  us  to  several  revelations  of  the  rapid 
prototyping  and  development  approach. 
We  found  some  key  characteristics  that  are 
outlined  in  Table  1 . 

Rapid  prototyping  and  deployment 
challenges  included  development  of  a  new 
set  of  capabilities  that  didn’t  exist  in  the 
old  system,  and  training  and  re-training  a 
large  user  community  in  parallel  of  build¬ 
ing  software  and  testing.  New  functionali¬ 
ty  included  embedded  workflow  process, 
identity  management,  and  Web  access 
using  the  Secure  Internet  Protocol  Router 
network.  We  also  had  to  gain  security  cer¬ 
tificates  and  authority  to  operate;  because 
of  their  generally  long  lead  time,  we 
planned  for  these  issues  in  the  beginning 
stages.  The  stakeholders  treaded  in  unfa¬ 
miliar  territory  by  collaborating  closely 
with  users  and  knowledge  sharing  with 
other  contractors.  Risk  management  was  a 
collaborative  effort  that  emphasized  the 
software  development  phase.  The  greatest 
challenge  was  to  develop,  train,  and  con¬ 
duct  integration  testing  with  multiple  con¬ 
tractors  in  nine  months. 

Success 

The  initial  fielding  of  DRRS-A  capabili- 


Figure  1 :  E  xample  Agile  Process  Flow  for  the  Scrum  Development  Process 


Sprint  Backlog:  Backlog: 

Feature(s)  assigned  Items 

to  sprint  I  ^  expanded  [ 

by  team 


Scrum:  A  15-minute  daily  meeting. 

Team  members  respond  to  basics,  such  as: 

1)  What  did  you  do  since  the  last  Scrum  meeting? 

2)  Do  you  have  any  obstacles? 

3)  What  will  you  do  before  the  next  meeting? 


New  functionality 
is  demonstrated 
at  end  of  sprint 


Product  Backlog: 

Prioritized  product  features  desired  by  the  customer. 
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ties  were  successfully  developed,  taught  to 
users,  fielded,  and  supported  within  nine 
months  by  using  incremental  and  Agile 
methodologies  [6].  Subsequent  releases 
have  been  just  as  successful  adding  on 
existing  capabilities  and  deploying  new 
ones.  The  success  of  DRRS-A  and  its  net- 
centric  capabilities  include  improving  user 
accuracy,  ease  of  use,  and  decreasing  man¬ 
power  and  manual  input.  As  an  example 
of  cost  realization,  the  US  ARC  cited 
DRRS-A  Web-based  applications  savings 
that  are  expected  to  be  more  than  $1  mil¬ 
lion  annually,  and  the  Army  Reserve 
Medical  Command  has  saved  what  aver¬ 
ages  to  be  $118,933  per  month.  The 
DRRS-A  capabilities  are  part  of  the 
Defense  Information  System  Agency’s 
Net- Enabled  Command  Capability  pro¬ 
gram  and  readiness  model  for  the  U.S.  Air 
Force  and  Marine  Corps. 

Conclusion 

Lessons  learned  during  program  develop¬ 
ment  and  fielding  have  brought  the  impor¬ 
tance  of  collaboration,  communication, 
and  risk  management  to  the  forefront  of 
the  Agile  development  process: 

•  A  tight  collaboration  of  several  con¬ 
tracting  teams,  stakeholders,  and  pro¬ 
gram  offices  is  necessary  to  prove  inte¬ 
gration  of  the  right  requirements  into 
the  software. 

•  The  set-up  of  checkpoints  during  the 
process  is  crucial  to  ensure  that  devel¬ 
opment  was  meeting  the  customers’ 
needs. 

•  Without  the  communication  and 
involvement  of  stakeholders  and  cus¬ 
tomers,  there  would  be  limited  sharing 
and  transfer  of  knowledge  that  can 
hinder  synchronization  across  the  bat- 
tlespace. 

•  It  is  easy  to  concentrate  on  risk  man¬ 
agement  in  the  software  development 
stage  since  it  is  the  meat  of  the  pro¬ 
gram,  but  lessons  learned  has  taught  us 
that  all  of  the  other  life- cycle  stages 
need  to  be  risk- analyzed  and  evaluated 
often  during  rapid  development.  For 
example,  training  needs  to  be  planned 
up-front  and  during  development  or 
else  there  won’t  be  ample  time  to  train 
the  user  community.  This,  in  turn, 
could  lead  to  program  failure. 

As  stated  in  the  introduction,  our 
intent  was  to  give  a  current  successful  data 
point  to  the  DoD’s  evolutionary  acquisi¬ 
tion  strategy  using  an  Agile  life-cycle 
approach.  We  have  also  proven — through 
cost  and  user  acceptance  of  this  system — 
that  DoD  life  cycles  can  be  developed  and 
maintained  using  Agile  methodologies. 
With  an  aggressive  schedule  and  high  pro¬ 


gram  visibility,  we  broke  traditional  devel¬ 
opmental  and  cultural  barriers  by  imple¬ 
menting  an  Agile  and  evolutionary 
approach  to  rapid  prototyping,  develop¬ 
ment,  and  fielding.  It  was  critical  to 
implore  a  knowledge- sharing  environment 
between  contractors  and  a  close  collabora¬ 
tion  between  the  functional  proponents 
and  users,  which  in  turn  laid  the  ground¬ 
work  for  success.  Our  Agile  and  flexible 
approach  to  systems  and  software  engi¬ 
neering  allowed  us  to  capture  the  true 
essence  of  rapid  prototyping  and  capabil¬ 
ity  deployment  while  still  meeting  bud¬ 
getary,  schedule,  and  customer  satisfaction 
goals.^ 
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